The present invention relates generally to techniques for developing and delivering virtual machine implementations. More specifically, the invention relates to techniques for creating virtual machine implementations that may be exchanged without requiring modification of the supporting libraries.
The Java™ programming language is an object-based high level programming language developed by Sun Microsystems, Inc. of Palo Alto, Calif., and is designed to be portable enough to be executed on a wide range of computers ranging from small devices (e.g., pagers, cell phones and smart cards) up to supercomputers. Computer programs written in the Java programming language (and other languages) may be compiled into Java virtual machine instructions for execution by a Java virtual machine implementation. In the abstract, a virtual machine interprets virtual machine instructions.
The Java virtual machine is commonly implemented in software by means of an interpreter for the Java virtual machine instruction set, but in general may be software, hardware, or both. Conventional virtual machine interpreters decode and execute the virtual machine instructions of an interpreted program one instruction at a time during execution, e.g., “at runtime,” which is in contrast to compilers that decode source code into native machine instructions prior to execution, e.g., “at compile time,” so that decoding is not performed during execution. Typically, the Java virtual machine implementation and support libraries, which together constitute the Java™ runtime environment, will be written at least in part in a programming language other than the Java programming language (e.g., the C++ programming language).
Computer programs in the Java programming language are arranged in one or more classes or interfaces (referred to herein jointly as classes). Such programs are generally platform, i.e., hardware and operating system, independent. As such, these computer programs may be executed, unmodified, on any computer that is able to run an implementation of the Java™ runtime environment. A class written in the Java programming language is compiled to a particular binary format called the “class file format” that includes Java virtual machine instructions for the methods of a single class. In addition to the Java virtual machine instructions for the methods of a class, the class file format includes a symbol table as well as other ancillary information associated with the class.
A conceptual view of a conventional implementation of the Java runtime environment is shown in FIG. 5. As seen therein, the Java runtime environment 251 includes support libraries 253 and executable program 257 incorporating a Java virtual machine implementation 255. Support libraries 253 are also known as built-in or standard class libraries. Support libraries 253 include Java methods that may be implemented through the use of native functions. Such native functions may be delivered, in addition to Java virtual machine implementation 255, as part of executable program 257. The native functions in executable program 257 typically include functions for controlling the virtual machine and for providing platform specific functions like I/O, graphical windowing, networking, and the like. It should be appreciated that the native functions may be written in any number of different languages and are typically written in a language other than the Java programming language.
Java virtual machine implementation 255 also includes a class loader and a verifier. There is typically no clear interface between the class loader or class verifier portions of a Java virtual machine implementation and the remainder of that virtual machine implementation. Similarly, there is typically no clear interface between the native functions and the virtual machine implementation because the various components of the Java runtime environment may be designed at the same time. Accordingly, the class loader, verifier, and native functions may be written with assumptions about the Java virtual machine implementation. For example, they may be written to utilize specific data structures used within the Java virtual machine implementation. If a developer desires to change the Java virtual machine implementation, a substantial amount of time may be required to rewrite or modify the class loader, verifier, and native functions to work with the new Java virtual machine implementation.
The support libraries 253 may also include additional native functions or other methods that are at least partially dependent on the specific implementation of the Java virtual machine utilized in the Java runtime environment. For example, many operations that the support libraries perform require access to data structures managed by the Java virtual machine or services provided by the Java virtual machine (e.g., threads). In conventional implementations this significantly limits the modularity of the support libraries since any class library that includes an implementation dependent function would potentially have to be rewritten or modified to accommodate a new Java virtual machine implementation.
It view of the foregoing, it would generally be desirable to provide a modular runtime environment architecture where the functionality provided by the support libraries may be shared by multiple virtual machine implementations. It would also be desirable to provide innovative techniques of developing and delivering virtual machine implementations that would allow virtual machines to be exchanged with essentially no impact on the support libraries. Conversely, it would be desirable to facilitate the exchange of support library implementations with essentially no impact on the virtual machine implementations.